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AMUS office hours are from 8s00 AM to 5:00 PM, 
Mountain Time. Our overworked secretary is 
Sharon Greene who is happy to assist you with 
any question you might have about AMUS, or the 
Alpha Micro Computer. If she doesn't know the 
answer to your question, she will try to direct 
you to someone who does. 


The AMUS Newsletter is published monthly and 
sent to all AMUS members. Additional copies 
and back issues of the newsletter mav be 
ordered from Sharon Greene. Bug, 
fixes, articles, letters, reviews of software 
and information about Alpha Micro applications 
are happily accepted, material must be received 
by the 20th of the month for inclusion in the 
following month's edition. 

The AMUS Newsletter is published monthly by 
AMUS, P. O. Box 1723, Boulder, Colorado 80306. 
Subscription rates are $7.50 per year. 
Application to mail at second-class postage 
rates is pending at Boulder, Colorado 803Q2. 

Each member representative receives a one year 
subscription to the Alpha Micro User * s Society 
Newsletter, the cost ($7,50) of which is 
included in the annual dues. 


The Alpha Micro Users Society Network is a 
computer system meant to give members access to 
information and other Alpha Micro users with 
similar interests. It consists of an Alpha 
Micro computer with a Hawk disk drive, a 300 
baud modem, a 1200 baud modem, and 16OK of 
memory. AMUS members are given an individual 
account and password on the Network so that 
they may receive personal electronic mail. 
Many thanks to Alpha Micro Systems in Irvine, 
California? North America Title Co. of Houston, 
Texas? and The Byte Shop of Reno, Nevada who 
have donated equipment and software to the 
Newtork. 


AMUS has a library of programs that have been 
donated by members for distribution to other 
members. Programs are available either through 
the AMUS Network, or, if you prefer, we can 
make floppy or Hawk cartridge copies and mail 
them to you. Orders may be placed through 
Sharon Greene. 



FROM THE EDITOR 


WHOOPSIE i l ! 


I'm afraid we've created a monster! The 
opportunity to place a one page ad in this 
newsletter each month and reach all you lovely 
subscribers has enticed over 50 members to do 
just that - to the point that this is an 
advertising media rather than the information 
tool it was designed to be. Our printing and 
postage costs have soared beyond the practical 
point and now prohibit the continuation of this 
practice. 

Soooooo.we had to make a decision this 

month. Except for some notices about Fortran, 
Cobol and Forth, the only ads in this issue are 
for used equipment. Henceforth, advertising 
will be at the rate of $50.00 per page, with a 
minimum of 1/4 page. This decision was reached 
after polling all members of the board of 
directors. Since this is a democracy, if 
anyone strenuously objects to either this 
policy or the charge, please drop me a note 
with your your recommendations and reasons 
therefor. 

All who submitted ads which were not printed 
have been notified of this change and requested 
to forward a disposition of their pending ad. 


New Educational User's Group 

Tacoma Community College, Tacoma, Washington, 
is forming a new educational computer users' 
group to exchange programs, identify who is 
doing what, where, etc. For more information, 
contact 

David P. Habura 
Dean of Instruction 
Tacoma Community College 
5900 S. 12th Street 
Tacoma, Washington 98465 

or contact your editor - I have an application 
and would be happy to mail anyone a copy upon 
request. 


Unlike most media publications, we print 
retractions in BOLD PRINT in the front, not 
buried in tiny little letters in the back. 

A SINCERE APOLOGY TO JOHN WYCOTT OF THE BYTE 

SHOP OF RENO. DUE TO A TYPOGRAPHICAL ERROR, 

JOHN'S AD FOR THE USER ACCOUNTING SYSTEM WAS 

PRICED AT $195.00 - IT SHOULD HAVE BEEN 

$495.00. (I hope John doesn't charge me the 

difference) 


DUE TO THE COMPLEXITY OF INSTALLING UAS, IT 
WILL BE SOLD AND DISTRIBUTED THROUGH LOCAL 
DEALERS. PLEASE CONTACT YOUR DEALER OR JOHN 
FOR MORE DETAILS. 


TIDBIT 

Steve and I recently had the same problem with 
similar Diablo printers and thought we would 
share our new-found knowledge with you. These 
printers would intermittently go into an error 
condition and stop printing. There was no 
correlation anyone could find except the IBM 
copier running upstairs (I should have known). 

I finally lowered myself to performing a 
totally obscure and unheard-of (and I might add 
time-consuming) task. I read the manual. In 
two volumes of operation, maintenance, 
protocol, etc., in a tiny hidden paragraph was 
'Some modems require the signal ground and 
protective ground lines in the interface 
connector to be disconnected'. Soldering iron 
out and loaded for bear, I spent two minutes 
removing one jumper. 

After over 30 hours of sweating over this 
thing, and even some service calls, the printer 
runs fine. It seems this jumper creates a 
ground loop and allows noise in the line to 
create a device error. So if you own a Diablo 
printer, and if you can't make it run 
consistently, call us.we're cheap. 

Pat 


Due to Christmas, hardware failures, and busy, 
busy people, this newsletter covers October and 
November 1980. We will st^rt fresh with 
December and begin 1981 with a real monthly 
newsletter. Merry Christmas, Happy New Year 
and all that good stuff to all of you from the 
Amus staff - we wish a prosperous and 
hardware-free 1981 to all (especially us). 





E M S 


Electronic Messaging on the Alpha Micro 

Electronic Messaging is beginning to be 
recognized as an extremely valuable tool in the 
busness world. Amid lowering productivity in 
white collar positions, and increasing 
percentages of the labor force being devoted to 
clerical and managerial positions. Electronic 
Messaging Systems (EMS) are demonstrating their 
capability to increase the speed and 
effectiveness of communications within an 
organization. 

EMS has been around for several years, mostly 
being used by larger corporations who have been 
tested out its use on a small segment of the 
organization. The true value of EMS, however 
is not realized until almost every individual 
of an organization has access to the system. 
At that point, every person in the company has 
direct access to every other individual. The 
president can send out a memo, and be confident 
that every employee will receive it in the 
shortest possible time. 

The personnel department can send an euquery to 
any employee and receive the answer with a 
minimum of interruptions in work. Since the 
answer to an enquery will already be 
electronically stored, it can be instantly 
filed without recopying. 

The Alpha Micro computer now has the capability 
to handle Electronic Messaging. This means 
that small company willing to take the leap 
into the electronic office by providing each 
employee with access to a terminal can take 
advantage of the considerable increases in 
productivity that a centralized computer and 
EMS can offer. EMS coupled to phone 
communications, makes it possible for employees 
at remote locations to be in close touch with, 
the home office. 

A report by Raymond R. Panco and Rosemarie U. 
Panco entitled "A survey of Corouter Mail Users 
at Darcom" listed a dozen improvements that 
Electronic Mail made in productivity for 
Managers, Professionals, and Secretaries. 

EMS is not without its problems. In very large 
systems, names of participants becomes a 
problem. There Might be three James Johnson’s 
and a sender would have to be able to discern 
Jiml from Jira2 from Jira3. Heavy users of EMS 
are able to use its ability to send multiple 
copies of one item and could produce a deluge 
of information that would slow down the 
operation. How do you allow employees to send 
an important message to all the other company 
employees when necessary, but restrict them 
from sending out announcements of their 
upcoming garage sale on Saturday? How do you 
handle an employee that leaves the organization 
with 72 items left in her mailbox? How about 
the boss who can’t type? How about the boss 
who delegates all the electronic mail to a 
secretary - you don’t realize this, and send 
VERY personal message about his activities at 
the last Los Vegas convention... 


EMS will not replace travel, phone calls, or 
staff meetings. However, it can make an 
organization more efficient, and make travel,’ 
phone calls, and meetings run smoother by 
providing information prior to meetings, 
cutting down filing and retrieval time, and 
dissemihating information directly to those who 
need it. 

At AMUS headquarters in Boulder, Colorado, the 
Electronic Mail and Bulletin Board system built 
by the Byte Shop of Reno is being used by the 
staff to keep track of problems submitted by 
members, forward phone messages, submit 
articles for the newsletter, and just plain 
fun. The power of the system stems from its 
simplicity, availability of help, and forgiving 
nature. 

A new user need about ten minutes of 
instruction, mostly that if you need help, type 
in the word HELP. If you are in doubt about 
what to do, hit a RETURN. In most cases, it 
takes you onto the next prompt without damaging 
any message already in the system. Prompts are 
concise and informative, instructions entered 
by the user are simple, and easy to remember: 
Send, Read, Scan, Forward, Delete, and Quit are 
all the commands that a user needs to know to 
begin using the system. Since all messages are 
postmarked with the day and time, you know what 
has been ignored the longest. Keeping one’s 
Mailbox empty becomes a normal part of a 
working day. Frequent users check in about 
three times a day and find that most messages 
can be dispatched quickly with phone call, or a 
reply entered immediately. 

Alpha Micro dealers should be aware of the 
potential for increased sales by offering the 
EMS package as part of the computers 
capabilities. In addition to showing a company 
how a computer can increase productivity, you 
sell more terarinals and memory. Coupled with 
VUE or another word processor. Phone 
communication capability, and a good data base 
management system, the Alpha Micro computer 
competes well with any Electronic Office system 
offered today. The Electronic office system 
software package offered by Prime Computers 
costs $20,000 and sits on an $150,000 machine. 
Such a system might serve 32 simultaneous 
users. An Alpha Micro Package with the same 

capabilities might consist of two AM-lQOT's 
linked together and cost one half the price. 


ske 
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FINAL 


F R EE PLAN N I N G 

W URKSHUP/SEMINAR 
FOR ALPHA USERS 


FINAL - FlNanciai Analysis Lansuase is a manasement tool fori 

* Cash Flow Analysis 

* Investment Analysis 

* Budsetin3 

* Business Plannins 

* 'M h a t If' Analysis 

* Consolidations 

FINAL is a simpler yet powerful Model ins Lanauaae. IJs ins an English 
vocabulary of about fifty terms you can tell FINAL what your data 
the required oalculationsr and the exact layout of your reports. 


Please contact me to resistor for the workshop? or to receive a colour 
brochure on FINAL. 

Mo Mo 

No Nonsa 
President 




CANADIAN TIME SHARING INC. 

67 YONGE STREET, SUITE 1510, (416) 366-5676 

TORONTO, ONTARIO M5E 1J8 



letters 


A. A. Holder 

Graphic Computer Services Ltd. 

50 Barclay Road 
London, S.W. 6 . 

England 

Dear AMUS: 

Thank you for yor prompt attention. We have, 
however, not yet received past copies of your 
newsletter. I am sure we will find them a 
valuable addition to our Alpha Micro library of 
bug fixes, etc. 

Some of your other readers may also be 
interested in knowing about our most recent 
experience. One of our clients directly 
acquired its second Alpha Micro computer. This 
time the 100-T model with 192kb of memory and 
double density CDC floppy discs. His first is 
a standard AM-100 with 192kb of memory 
supporting 2 Hawk drives, 5 VDV’s and a 
printer. Here follows a weekly account of the 
fun to come. 

WEEK 1: 

The first two days were spent getting familiar 
with any hidden subtilties which 4.4 might have 
in store for us, like amending the Hazel driver 
to respond to Vue; finding out if DSKPAK worked 
ok and doing ISMFIX on our 4.2 generated files, 
as well as recompiling our huge library of 
well-established programs. 

While all this was going on, the system had the 
unfortunate problem of rebooting itself. We 
supposed at once that the 100-T processor must 
be more sensative to unclean power supplies. 

On the third day the system was connected to a 
clean power. Several attempts were made to 
reboot but without joy. Covers off and 
somewhat alarmed the investigation started. 

All the boards seemed in order and firmly in 
place. Moved the CPU board one slot over, 
powered up and the system happily rebooted 
itself. 

Our first diagnostic was that the board might 
have gotten dislodged while the box was being 
moved about. By the way, the plastic guide 
rails which hold the larger board set seemed to 
us quite inadequate and somewhat fragile. 

Next we decided to leave the machine running 
overnight performing some trivial tasks. In 
the morning, all seemed well but while thinking 
up some performance tests, the system rebooted 
itself but failed to complete System.INI. 
Several further attempts were made without 
success so the covers had to come off again. 

The symptoms were different this time. The 
heads of the floppy would not load. Checked 
all the connections, moved the CPU board again, 
but no change. 

More urgent matters called, so the fiddling 
around had to be left for a while; but on 
resuming our detective work, the system offered 
no hesitation in working perfectly the first 
time. 


The next thought was that the 100-T might be 
very sensative to temperature or at least more 
so than the plain 100. Even on the old machine 

we found that the single fan on the TEI box was 

inadequate, especially when becoming near full 
of boards. So the problem was simply overcome 
by mounting two extra fans on the side grill to 
blow air into the box and reversing the rear 
fan to suction. The same preventative action 
was taken for the lager 100-T box. The system, 

however, refused once again to boot and the 

disc heads would not load. 

WEEK 2: 

A more close examination of the 100-T processor 
revealed some real goodies. 

1 . 2 chips had a pin outside their 

sockets 

2 . 1 chip holder was making lousy 
connection on the board 

When this was put right, he system began to 
function and all appeared to be well. 

We cursed Alpha Micro for neglecting their 
quality control and for having wasted our time 
and our client’s money. 

More software tests were carried out and still 
unaware of the pitfalls of 4.4 we decided to 
hook up the Hawks and start running the new 
100-T with the live system. The increased 
performance was impressive and we all looked 
forward to an easy time ahead. 

The next few days, however, were really the end 
every 20 minutes or so a sudden and 
mysterious BUSS ERROR would appear. We swapped 
memories around, performed the available 
hardware tests and all seemed normal. 
Arithmetic operations in Basic were failing, 
i .e. , 

5+1 = 7 .- 15/0.45 * 

0.45 =15 15 * 0.45 / 0.45 = anything 

between 13.85.... and 18.67.... 

A few telephone calls to friendly Alpha dealers 
revealed that this problem could be cured by 
firmly securing the heat-sinks on all boards 
and including the mother-board. Some of these 
were found to be quite loose. [Quality 
Control?] 

The math problem was cured, but only for a 
short while, so a decision was made to revert 
to the old AM-100 and to hand over the 100-T to 
our competent service engineers. 
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WEEK 3: 


After nearly another week of investigations, 
none was any wiser, but to the fact that yet 
another hardware problem had been found. 

The clock line from the main power supply to 
the mother board was making a bad connection. 
[Quality control] After this repair, the 
system refused to work at all and since the 
warranty was still valid, we returned the 
processor to the supplier. 

Further tests were carried out with the 
engineers spare processor and we conclusively 
proved that heat, unclean main power supply, 
and not very tightly secured heat sinks, caused 
the system to behave in a strange manner. 

While we await news from our supplier, we 
thought of letting other 100-T users know some 
of the problems and it would be some 
consolation to know that Alpha Micro might 
consider testing their systems more thoroughly 
before shipping them. 

Thank you for a helpful magazine. 


COBOL EVALUATION 

As many of you know at NCC last May, Leo 
Scheiner with Computer Applications Research in 
London, England was showing a working copy of a 
COBOL package his company has developed. At 
that time, he offered to lend a copy to AMUS 
for evaluation. As an experiement in potential 
software evaluation, AMUS accepted and I 
volunteered to evaluate it since my company 
works with COBOL as a large part of our 
computing. 


9. There is a reasonable way to support 
screen functions. 

10. It is multi-user. Multiple users can 
run or develop COBOL programs 
simultaneously. 

Now some weak points: 

1. It requires a lot of memory. (COBOL 
is a very large language and this 
should be expected.) Thus, both the 
basic and COBOL run time packages 
cannot be in system memory at the same 
time. CAR COBOL requires a 32kb user 
partition and about 12k system memory 
to work. 

2. There are some logis.tic problems 
dealing with an overseas vendor. My 
last 

update floppy arrived bent completely 
out of shape and not usable. 

3. It does not include any of the common 
IBM 370 large mainframe extensions 
that my company (I have recetly 
discovered) uses all the ‘‘time. This 
is not a defect with the product, and 
in fact, CAR has expressed interest in 
implementing several of them, but a 
factor to consider if you are 
converting large mainframe COBOL 
programs to the Alpha Micro. 

4. There are still several minor bugs 
popping up in the system. Most of 
them can be programmed around. 

General comments: 


This is a very preliminary report of my 
evaluation to date. Several things have 
prevented me from being more timely and I hope 
to complete the evaluation soon. The release I 
am referring to in this letter is 3.0. 

First the good points: 

1. It works. 

2. The manual, documentation and error 
messages are intelligible. 

3. It includes a very good coverage of 
the COBOL language. 

4. The compiler and run time package are 
relatively fast. I don f t believe they 
are as fast as Alphabasic, but not 
much slower either. 

5. The people at CAR, Leo Scheiner and 
Tony Sales have been very helpful. 

6 . It appears to be equal to or better to 
any other small machine COBOL I have 
heard of or read about. 

7. It supports al types of Alpha Micro 
files, including ISAM. 

8 . It comes with about 10 sample programs 
which demonstrate how to use many 
types of statements, files, techniques 
in this implementation. 


The package appears to be a good product and a 
reasonable alternative for users who have COBOL 
programs and don’t want to convert them to 
Alphabasic. CAR is implementing many features 
for release in November, 1980, such as assembly 
language calls which will make the product even 
better. I understad there are about 5 
installations in the US and 10 in Europe at 
this time. I would welcome any input from 
these sites on their experiences, problems, and 
use of COBOL on the Alpha Micro. Also, I would 
welcome any input from potential users as to 
their specific questions or requirements in a 
COBOL package on the Alpha Micro to help use as 
a yardstick in this evaluation. 


For more information 
01 1-44-1-486-0702, 
or Tony Sales at 01 
the author 


, contact Leo 
10 St. Albans 
1-44-2-302-2788 


Scheiner 
, London 
. Tony 


at 


W8, 

is 


and best source 
questions. 


of information on technical 


Respectfully submitted, 
Eugene C. Platt 


5 



John E. Hewlett 
Modern Information Methods 
2751 E Chapman, Suite 205 
Fullerton, CA 92631 
(714) 738-6434 

As secretary of SC/AMUS, I have been authorized 
to make two suggestions to AMUS. 


I. As more and more areas of the country 
organize regional AMUS groups, it is 
probable that a great deal of 
duplication of effort will occur. It 
is our suggestion that each group 
volunteer for (or be assigned) one or 
more club projects. For example, most 
of our members are interested in 
seeing more competition in the area of 
Phoenix disk drives. To further this 
goal, we intend to encourage Konan (of 
Phoenix, Az) to start offering 
Phoenixes and disk controllers to A-M 
users. To assist them, SC/AMUS will 
assume responsibility for: 

a. Modifying any drivers, as 
necessary 

b. Keeping these drivers operational 
as A-M releases future versions of 
AMOS 

We suggest that AMUS should take the 
lead in co-ordinating and assigning 
such club projects, and in 
distributing the results of each 
project to other regional groups. To 
encourage the formation of other 
groups, and to share the work load in 
an equitable manner, we further 
suggest that the results of club 
projects only be distributed to other 
clubs who have accepted responsibility 
for at least one project. No workee, 
no benefits ! ! ! 


II. Our members are a little worried about 
the reliability of Phoenix drives. 
There seems to have been a rash of 
head crashs lately. We hear of most 
of the catastrophies in S. California, 
but we can’t accurately translate 
these sporadic incidents into 
meaningful reliability statistics. We 
could, of course, request such 
statistics from A-M and/or CDC, but 
I f m skeptical of whether or not they’d 
reply. And I’m not sure I’d believe 
their answers if they did. We suggest 
that AMUS take the lead in collecting 
and publishing reliability statistics 
on all the components of Alpha Micros. 
This, of course, will require a great 
deal of co-operation on the part of 
all AMUS members, since they really 
should send in a form (about once a 
quarter) describing not only any 
failures they may have had, but also 
an estimate of the number of hours 
(that quarter) their equipment has 
been used. If this were done with any 
accuracy, AMUS could publish quarterly 
figures on the MTBFs of each piece of 
hardware. 


Eugene C. Platt 

Vice President, Alpha Micro Users Society 
4834 Jason 

Houston, Texas 77096 
(713) 666-8166 


Where I w^k at North 
have dual 300 mb Tr 
them for almost two ye 
results. There have 
the last two years in 
because of the Trident 
times we were able to 
and the third time 
expertise not availabl 


America Title Company we 
ident disks. We have had 
ars and have had good 
been only three times m 
which our system was down 
subsystem. Two of those 
repair them ourselves, 
we required parts and 
e in the Houston area. 


Over the last several months I have talked with 

several of you who also have Trident systems, 
but I have not kept records of who you are and 
where you are. Since the Trident user 
community is one of smaller in Alpha Micro 
land, and technical- support and experience is 

widely spread pver the country, I would like to 
nffor naie a Trident share group. 


What I have in mind is a very simple system. 
Basically, I would like to assemble a list of 
the Trident systems, their size, location, and 
the name of the person who is responsible for 
the system. With this information the Trident 
users could hopefully exchange information 
concerning maintenance, backup, drivers, 
programming, and operating experience. 

If you have a Trident system, would you please 
send me a letter with the above information. I 
will then assemble this information and mail 
back to each of you a directory of all of the 
responses I get. Several times a year I will 
solicit new listings and updates and mail out 
current lists. 


I believe that this sharing can be very 
beneficial to every Trident user and I hope to 
hear from you soon. 


AMUS OFFICE NEW ADDRESS 


Amus has moved ! ! Our new address is: 

934 Pearl, Suite B 
Boulder, Colorado 80302 

The phone numbers are still the same; that is, 
if the phone company ever gets us hooked up 
again. Honest folks, the move was planned in 
conjunction with Ma Bell. 

The post office box is no more. We eventually 
get mail which goes there - it just takes a 
while. Please send your mail to the following: 

Anything to do with the newsletter to your 
faithful editor in care of: 

Dunn, Moore & Associates 
1401 E. Bridge Street 
Brighton, Co 80601 
(303) 659-1335 


SC/AMUS will be happy to assist, in any way we All other correspondence, dues, etc. to the 

can, to implement these suggestions. Pearl Street address in Boulder. 
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wishing 


well 


John Brady 

Dystat Computers 

50 Crown Street 

Wollongong 

New South Wales 

Australia 2500 

042-28-08-97 

John is seeking information regarding the 
interface of a Data Terminal Systems cash 
register to the Alpha Micro, and would greatly 
appreciate anyone with any experience at all 
contacting him. 


****** 


Dennis Schock 
Edgar, Nebraska 
402-224-4615 

Dennis is looking for a used Hawk Drive 


****** 


****** 


Sandi Miller 
Informatics, Inc. 

1508 Kennedy Drive, Suite 215 
Bellevue, Nebraska 68005 
402-291-8301 

Informatics is currently looking for a used 
Hawk drive. Sandi is also fairly accomplished 
in the use of TXTFMT and would be willing to 
help anyone with questions/problems. 


****** 


Pat Seitsinger 
Dunn, Moore & Associates 
1401 E Bridge Street 
Brighton, Co 80601 
303 659-1335 

This is going to sound pretty elementary to all 
you genuises out there who speak 
assembler. 

I'm looking for a good self-study book, course, 
ANYTHING on assembly language. Anybody know of 
one, please call me or leave a message for me 
on the network (leave mail for Pat). 


Richard N. Smith 
Northwest Computer Services 
P.~0. Box 1496 
Everett, Washington 98206 
(206) 258-4744 

Richard is currently looking for Sales 
Brokerage and Property Management software for 
a real estate agency. He would also like to 
know if there is any interest among Alpha Micro 
users in the Seattle area for seminars; he has 
office spare available for the seminars. 
Please contact Richard with the area of 
training and time factors. 


****** 


Eugene Platt 
4834 Jason 

Houston, Texas 77096 
(713) 666-8166 

Eugene is looking for a gas purchase system 
which runs on the Alpha Micro. 


CREATIVE SYSTEMS 
8101 SW Nybert, Suite 220 
Tualatin, Oregon 97062 
(503) 638-8406 

Last July, several dealers who performed 
maintenance services for Alpha Micro systems 
were endorsed by Alpha-Micro in the newsletter. 

CREATIVE SYSTEMS was inadvertently omitted from 
this list. 

CREATIVE SYSTEMS specializes in system design, 
hardware, software, service and, most of all, 
support. They offer a response time of less 
than 24 hours and have maintained an excellent 
reputation with their clients. 

Contact Mark J. Kloepfer, Service Manager for 
more information. 


Thank you 
’Bug List'. 

1 Suggestion 
Micro, this 
release of 
kind enough 
newsletter. 


to Bob Fowler and friends for the 
Perhaps a better name would be 
List'. In all fairness to Alpha 
list was prepared prior to the 
Version 4.4B. Maybe Bob will be 
to review 4.4B for us in the next 
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BUGLIST #15 (Version 4.4A) 


9/12/80 


Buglist #15 is titled "4.4A" for continuity's sake, but it all applies 
equally to 4.4. 

It appears that Buglist #13 was never published (sent 2/29/80). 

I am compiling a summary of all AMUS newsletter releases. If anyone out 
there has any data on actual (vs scheduled) 'release dates, I would be 
grateful if you would jot it down on a postcard and send to me at the 
address below. Usually, "actual release date" means "earliest known 
postmark date". I have only seen 3 postmarks so far. Do you have any ? 

The summary itself is all done except for "holes" in the data. One page. 

Just in case some of you thought these bugs are all my own, they aren't. 
Bugs come from myself, fellow employees, other dealers, and customers. 

For this buglist, I will follow each bug with a bracketed reference to 
the person "without whom this bug report would not have been possible". 

This will give some vague indication of how many people are actually 
contributing to this buglist, and partly to say "thank you" to all. 

If there is no bracket, the bug is from yours truly. 

Keeping the releases straight, we appear to have the following : 

4.4 - preliminary, to dealers, AM solicited comments 

4.4 + patches - DDT fixes given in Software Notes #2 (7/2/80) 

programs affected : BASORT,CRT410,DUMP,MOUNT,20ODVR 

4.4A - Final 4.4 release to users, FIX re-released (7/23/80) 

programs added : MENDEF.MAC,AM301.IDV,AM302.IDV 

4.4A + patch - DDT fix given in Software Notes #3 (8/5/80) 

OO fixes a minor potential problem in SYSTEM.MON 

New PASCAL - Released independently on PASCAL diskette (8/18/80 ?) 

4.5 - in the future; will include new PASCAL 


Bob Fowler 

Alpha Information Systems 
800 San Antonio Road 
Palo Alto, CA 94303 


AMOS BUGS (Version 4.4A) 


(1) Buglist #14 - Errata 

Bug (21) is not a bug. Use "HELP? <boolean>", not "HELP <boolean>". 
[thanks Gerry] 

(2) AM-900 Mainframe - Real-time CPU clock interrupt is consistently low 

The voltage of the clock interrupt line on the AM-900 mainframe is 
supposed to be "24v peak-to-peak" (about lOv RMS) according to page 3-1 
of the AM-900 documentation manual. In the very first schematic of 
section VI (sheet 1 of the cabling diagram), it also says "lOv AC". 
Wellllllll, so far we have received, tested, and used 4 or 5 AM-900s, 
all of which have had mainframe clock voltages centering in the range 
of 6.0v to 7.4v. If all the measurements taken here are included, no 
voltages were ever above 8.0v, and one dipped down into the 5-6v range. 

The most unfortunate part of all this is that the clock begins to 
lose interrupts somewhere in this lower voltage range. When our line 
voltage dropped slightly (sometimes due to an adjacent piece of harware), 
the cpu was subject to lose 99+ percent of the interrupts, causing 
an interrupt cycle of minutes, rather than milli-minutes. 

[thanks, Gerry] 

(3) VUE - sometimes deletes all characters following a null 

Use EDIT to create a file that has the following 22 characters : 

AAAAAAAAAAAAAAAAcr If nul A cr If 
Where I have added spaces above for readability; there are no blanks in 
the actual file, which looks like this on the screen : 

AAAAAAAAAAAAAAAA (16 letter A's) 

A (an "invisible" null) 

Now VUE this file, and the second line will disappear. "Finish" from 
VUE and the second line will be deleted from the file. In a large file 
this can cause great losses. Not all cases will manifest this problem. 

The only "problem" case simpler than the above that I know of is : 
cr If nul A cr If 

Which is 6 characters. After being VUE'd, it becomes the 3 characters : 
sp cr If 

Everything after the null is lost and (due to a VUE quirk) a sp is added. 

Note : there are nulls in the 4.4 MENU.VUE - if you attempt to VUE 

this file to change it, VUE will appear to load only 2 odd-looking lines. 
If you then exit with an "F", you will lose the rest of MENU.VUE ! 

(4) VUE - control-B goofs when typed in middle of last screen display 

If VUE is in the process of writing the entire screen for the last page 
of a file, and control-B is hit during the time this display is in 
progress, the screen usually gets messed up. VUE is trying to save the 
user from having to wait for the initial display to complete, but it 
doesn't succeed in this case. To demonstrate this, get into VUE, use 
PAGE or control-T to get to the last page, and hit escape/escape/control-B 
in rapid succession. This is demonstarted best when there are about 
12 lines in the last screen. Until this bug is fixed, the display can 
be corrected by simply hitting escape twice. 



(5) VUE - entering lines longer than 80 characters goof up screen 


(10) BASIC - FILEBASE not reset correctly after CHAIN 


Enter a line (or edit an old line) so that you end up at the right end of 
the line, with more than 80 characters. Call this "line A". Now hit 
return. The cursor will be (correctly) positioned at the beginning of 
the next line, or "line B". VUE now knows that some lines on the crt 
(ie, line A) are not left-justified, and must be re-displayed, so it 
re-displays line B. Unfortunately, it re-displays line B before 
re-positioning the cursor, so lines A and B both look like line B. 

For now, if this happens, clean up the crt by hitting escape twice. 

To prevent it from happening, hit control-u before the carriage return. 

(6) VUE - can't VUE files with extension of ".ZZZ" (!) 

Try typing "VUE A.ZZZ" and see what happens. VUE will act as if no 
extension had been typed, and will go to the INI.VUE file and use the 
default extension given there? if there is no INI.VUE, it will assume 
the extension "MAC". This doesn't appear to happen with any other 
extension 1 


If "FILEBASE <n>" occurs in any program (n>0), and a CHAIN occurs, and 
the destination program has no FILE3ASE command, then this second 
program will READ random file records as if FILEBASE n were still in 
effect, but "Illegal record number" error messages will be reported as 
if FILEBASE 0 were in effect. Thus, the most likely case will be the 
most bizarre, namely the following : 


FILEBASE 1 (in first program) 

CHAIN "FRED" (chain to second program) 

OPEN #1,"FRED",RANDOM,512,RECNUM (in second program; no FILEBASE) 
RECNUM=0 

READ #1, X (where X is properly MAPped ) 

The contents of X will be record "-1" in the file; AMOS will read in 
a block outside of the file ! But no errors will be given, since the 
error message is reacting as if FILEBASE 0 had indeed been reset, 
[thanks, Lai] 


(11) BASIC - INPUT doesn't reset TAB counter 


(7) VUE - YANK <filename> at begininning of file doesn't function properly 

Start with any VUE file, position the cursor at the very beginning (using 
control- 7 ') , then go to the menu and do a YANK <f ilename> using any insert 
file you want. Now return to editing mode (hit escape). You will find 
that, prior to executing the YANK, VUE improperly rolled the screen up 1 
line (leaving line 2 at the top of the screen), thus re-positioning the 
cursor at the beginning of line 2. When the YANK was then (properly) 
executed, the insert file ended up between lines 1 and line 2, rather 
<X> than before line 1. If you now hit control-% line 1 will re-appear, 
immediately preceeding the insert file. 

(8) VUE - unreliable screen update of >80 character lines while time-sharing 

This bug is a bit of a sprite, and will elude attempts to track it down, 
but the following circumstances should make it show itself. 

Use a system with at least 2 terminals (ours is a Phoenix, if that helps). 
Use VUE to create a file with "several" lines longer than 80 characters. 
Then, while the other job does some intensive activity (try a REDALL), 
hit escape twice to repaint the screen. Keep hitting double escapes, 
and (hopefully) you will find that, at random times and random lines, 
columns 75-80 on the crt will get messed up (on >80-character lines). 

We used just a 3-line file, with 100 characters in each line, and got 
messed-up lines on about half of the crt "re-paints". I recommend 
using the following 100-character line, to make the goofs stand out : 

"00000000001111111111222222222233333333334444444444...<etc>..." 

If this fails, try more & longer lines. 

(9) BASIC - integer variables aren't INT'ed on INPUT statements 

According to the AlphaBASIC manual, variables ending in % are stored 
as F6, but automatically truncated as if they were true integers. 

This fails in the case of inputs, as demonstrated by the following : 

10 INPUT A% 

20 B-A%+A% 

30 PRINT A%,B 

Enter "1.1" to this program, and "1.1 2.2" will be outputed. 


It is well-known that you are not supposed to single-TAB backwards, eg, 
PRINT "HELLO"; TAB(2); "HI" (try it !) 

On a backwards TAB(n), AlphaBASIC effectively executes 
PRINT CHR(13)? SPACE(n)? 

Thus erasing any output on that crt line up to the ending TAB position. 
(Note that on printer output this works exactly as one would like it to.) 
None of this so far is a bug (although it would be nice if backwards 
tabs didn't output all those erasing spaces; hard to debug at 9600 baud). 
The bug is in the INPUT statement, which fails to reset the TAB counter. 
Thus, the following will get messed up : 

PRINT M? TAB(10); "ENTER NEW VALUE : "? : INPUT M 

PRINT N? TAB(10); "ENTER NEW VALUE : "? : INPUT N 

The second PRINT'S output will get cleared from column 0 thru column 9. 

A fix is to insert between the two lines the following : 

PRINT : PRINT TAB(-1,3); 

This bug is very old, & was reported in Buglist #8 (Jul 1978 newsletter), 
[thanks, Lai] 

(12) BASIC - a bizarro special for certain types of incorrect syntax 

Create the following incorrect-syntax program in VUE or EDIT : 

10 A$=B$( 

Now" GO" from VUE or COMPIL from AMOS. COMPIL will display "illegal", 
then " - ", then it will hang up for 115 seconds, leave the error 
message incomplete, display the incorrect line, and exit (no AMOS crash). 
BASIC itself has no problem with this, giving a "Syntax error" message. 
Other simple, one-line programs that demonstrate the same problem are : 

10 A$=B$() 

10 A$=B$([ 

10 A$=B$([1,11) 

10 A$=A$([INSTR(1,A$,A$) ) 

However, if numeric variables are used (use A,B in place of A$,B$ above), 
COMPIL will not hang up, and in all cases will give no error messages 
[thanks to Lai, Dr Fogg, and myself] 

(13) COMPIL - lets bad syntax by 

The following one-line program will be compiled by COMPIL ; 

10 PRINT "A 

and, when RUN, will display an "A". BASIC will reject the line, however, 
[thanks. Bill] 



(14) EDIT -- beware FS on crlf when tabs are present 

Create a file it r EDIT it, then type the following : 

I TAB A CR ESC ESC 

This inserts a tab,A,cr,If (4 characters) into the file. 

Then try the following global search and replace : 

F S CR CR ESC CR ESC ESC 

We get several dozen buss errors here before AMOS dies. 

(15) TXTFMT - nulls turn on underlining 

If TXTFMT encounters a null in an input file, the output file will 
contain underlining. The simplest clear example is s 
nul A cr If 

Which is 4 characters. After being TXTFMT 1 ed, the output is : 

A bs _ cr If If 

Which is a total of 6 characters. 

(16) FMT210 - set TIME afterwards 

Running FMT210 off of a Phoenix system, we find that the format takes 
about 55 seconds; during this time the system TIME has advanced about 5 
seconds. Evidently, FMT210 is so intensive that it not only precludes 
any other active jobs (dealers see Alpha's Software Newsletter #2), but 
also locks the real time clock up so tight that less than 10% of the 
interrupts are getting processed 1 Moral : keep other users off, and 
reset the TIME afterwards. 

(17) BASORT - documentation says it can be done, but it can't 

The following sample (sequential) file sort works fine : 

10 OPEN #1, "BOBl.DAT", INPUT : OPEN #2, "BOB2.DAT", OUTPUT 
“ 20 XCALL BASORT,1,2,10, 5,1,0, 0,0,0, 0,0,0 

^ 25 1 XCALL BASORT,1,1,10, 5,1,0, 0,0,0, 0,0,0 

30 CLOSE #1 s CLOSE #2 

The BASORT documentation says that a sequential file may be sorted onto 
itself by using equal channel numbers in the XCALL BASORT statement. 

For instance, in the above example, use line 25 in place of line 20. 
However, this causes an error message from BASORT : 

?File improperly open in XCALL BASORT 
[thanks, Ron Cochran] 

(18) BASORT - documentation still says it has to be loaded into memory 

A long time ago, in a galaxy far far away, BASORT had to be loaded into 
memory before being XCALLed (like all subroutines at that time). But 
now it can be auto-loaded at XCALL time. The documentation for BASORT 
(in the 4.4 release notes and the SBR.TXT Accounting doc file) still 
does not reflect this (ages old) improvement. 

[thanks, Gerry] 

(19) PRINT - documentation doesn't mention global switches 

Like many other utilities, PRINT has both global & local switches. 

The global switch syntax is not mentioned in the documentation, however. 
For example, to get no form feeds on several files, enter : 

PRINT/NOF FORM1.TXT,F0RM2.TXT,FORM3.TXT,FORM4.TXT 
[thanks, Ron Cochran] 


(20) INPUT.SBR - backspace only works properly as first input character 

If backspace is the first input to an XCALL INPUT with a TYPE field of 
"?E" (see documentation for details), then "END" will be returned. 
However, if 1 or more valid characters are entered, then an infinite 
number of backspaces can be entered, going outside the input field, 
beyond the input line, and onward to complete crt wrap-around. 

(21) PRINT.SBR - Leaves print string as "" after XCALL 

The third parameter passed to XCALL PRINT is the actual line to be 
printed. After XCALL PRINT, this variable is being set equal to 
Thus, if the same line is to be printed twice, and 2 XCALLs in a row 
are made, you will find that the second line actually ends up blank. 

Is this intentional ? Nothing is said about this in the documentation. 

For a sample XCALL PRINT program which points this out, see following. 

(22) PRINT.SBR - PPN on the CONAME filename causes suppression of FF option 

All the particulars of this bug are covered in the following program. 

This bug is referred as bug #1; bug #2 is the one mentioned above. 


10 REM . DEMO OF FF OPTION BUG IN "PRINT.SBR[7,6]” 

11 REM . MUST PRE-LOAD INTO MEMORY : FLTCNV.PRG & PRINT.SBR 

12 MAPI TT,S,10,"TITLE" 

13 MAPI LC,F,6,99 l 99=DON'T USE CONAME.DAT 

14 MAPI PC,F,6,0 I PAGE COUNT 

15 MAPI PL,S,4,"LINE" 

16 REM . BUG #1 : IN FOLLOWING STRING (CN), 

17 REM IF PPN IS ABSENT, FORM FEEDS ARE OUTPUTED BY XCALL (CORRECT) 

18 REM IF PPN PRESENT, LINE FEEDS ARE OUTPUTED BY XCALL (INCORRECT) 

19 REM BUT NOTE : CONAME IS NOT USED (NOR OPENED) BY XCALL PRINT 

20 MAPI CN,S,25,"DSK0:CONAME.DAT[1,4]" ! USE ANY dev AND ppn 

21 OPEN #1, "BUG.LST", OUTPUT 

22 FOR 1=1 TO 60 

23 REM . BUG #2 : NEXT LINE IS NEEDED TO RE-INSTATEMENT PRINT STRING 

24 PL="LINE" 

25 REM . BUG #1 : FOLLOWING SHOULD OUTPUT FORM FEEDS (NOT LINE FEEDS) 

26 XCALL PRINT,LC,PC,PL,TT,"NO HDR""NO LEGEND"1,80,80,0,1,CN,0 

27 REM . BUG #2 : PL l£ NOW A NULL STRING 

28 NEXT I 

29 CLOSE #1 

30 REM . BUG #1 : TYPE OUT "BUG.LST" AFTER RUN & SEE THE LINE FEEDS ! 

(23) PRINT.SBR - truncates title field to 50 characters after page 1 


On page 1, the title field is not centered, and can be > 50 characters. 
After page 1, the title field is centered between the date & page #. 
Evidently, PRINT truncates it to avoid running out of room, but this 
is not mentioned in the documentation. Or else, it is a bug. 

[thanks, Gerry] 









(24) SPOOL.SBR - messes up at least one variable 111 


AMOS SUGGESTIONS (Version 4.4) 


Try running the following program and seeing what happens : 

10 FNAME $="BUG.LST" 

20 1=1 

30 OPEN #99, FNAME$, OUTPUT : PRINT #99, "HELLO" : CLOSE #99 
40 PRINT I 

50 XCALL SPOOL, FNAME$, "", 132 
60 PRINT I 

The first display of I is "1" (ok), but the second display is some 
other arbitrary number; if you change the program slightly, this 
arbitrary number will change to another arbitrary number ! 

After fooling around awhile, I think it is 'always the last variable in 
the BASIC variable table which gets messed up, but I'm not sure. 

This bug has probably escaped detection for so long because most 
applications (eg. Alpha Accounting) CHAIN immediately after XCALL SPOOL, 
(thanks. Bill! 


(25) COPY - adds a 64th PPN to the MFD 

The MFD has room for 64 PPN's, but the last one is always supposed to be 
empty, because SYSACT uses it as an end-of-MFD marker. Global COPYs will 
go ahead and insert a 64th PPN, however. If SYSACT is then used to delete 
any PPN's, the 64th PPN will become the "junk" that was present in memory 
at the "65th PPN" location. 

[thanks, Gerry] 

(26) SPOOL.SBR - docs should say that FLTCNV must be pre-loaded into memory 

The documentation for SPOOL.SBR does not say anything about this. 

— In addition, the list of error messages does not include the error 
given if FLTCNV isn't found in memory. 

(27) Phoenix 4.3A to 4.4 conversion document - bad advice for no-boot case 


The document DWM-00100-71 (titled STOP I in huge letters) is being sent 
with 4.4.A releases, warning of the importance of 4.4 to Phoenix users. 

It has very bad advice to users who find that their 4.4 update wont boot. 
Section 1.2.2 instructs the user who normally boots off a cartridge to 
boot off the 4.4 update cartridge? it doesn't consider the no-boot case. 
Section 1.1.4 instructs the user who normally boots off a fixed disk to 
boot off the update, & if it fails to boot, to boot off the 4.3A fixed 
disk & then use a 4.3 operating system to change the SYSTEM.INI on the 
4.4-certified disk ("and bad tracks be damned", eh Alfie ?). This is bad. 
If your 4.4 Phoenix update doesn't boot, the only safe procedure is to 
boot off of a cartridge 4.3, type RES to LOAD all necessary utilities, 
preserve the SYSTEM.INI in some place like DSK2, load the 4.4 cartridge, 
COPY contents to DSK1, restore the SYSTEM.INI, & boot off the fixed disk 
(eg, MONTST DSK1:SYSTEM). At this point, you are running a 4.4 

system on a 4.3-certified disk, which is ok. You may now edit the 4.4 
cartridge. 


(1) VUE - allow control-S to interrupt a screen update 

As of now, control-T, control-R, control-E, control- A all interrupt a 
screen re-paint (if one is in progress). Please add control-S also. 

(2) VUE - un-implement control-rub ?? 

It is not normal to take a "step backwards" in software, but I am sure 
that I am not alone in my agony over continually hitting control-rub 
accidentally instead of plain rub (thus losing a whole line). 

I rarely use control-rub intentionally, and would rather see it gone. 

If other users agree, write AM and say so; I may represent a minority, 
but I don't think so. Remember, control-rub only saves 1 key stroke. 

Or, how about a new command to "undelete" a control-Z or control-rub ? 
Easy to implement : simply change VUE so that a control-z or rub actually 
"MOVE"s the line to the end of the file (just like MOVE), but looks gone. 
This would very easy to implement because most of the code already exists 
The only hard part would be trying to scrape up another control character 
[thanks, Gerry] 

(3) SCNWLD —- ersatz name cleanup 

"DIR OPR:" and "DIR LIB:" should be added; "DIR MPL:" should be deleted. 
This would make the SCNWLD ersatz name set consistent with that ir^ LOG. 

(4) DUMP - DUMP BITMAP could be even better I 

For those rare times when some poor devil actually wants to know the 
block corresponding to a particular bitmap bit, the DUMP BITMAP output 
could be made even more readable using the following format : 

"000001: 11111111 11111111 11111111 11111111 etc" 

Using this format, 79 characters would appear per line, avoiding column 
80 wrap-around problems. 

(5) CRT410 -— should add BADBLK to (1,21 slightly different 

As of now, BADBLK.SYS is entered into the [1,2] directory as a sequential 
file having 1 block, with 512 bytes "active" in the last block. Thus is 
somewhat unorthodox, since the first 2 bytes in a sequential are usually 
a pointer, leaving only 510 bytes for data. Thus, if you type : 

LOG OPR: 

LOAD BADBLK.SYS 
SAVE BADBLK.SYS 

You will find that BADBLK now has 2 blocks, with 2 bytes used in the last 
(second) block, because SAVE produced a "correct" directory entry for the 
file. None of this monkey business appears to cause any troubles. 

It would be best if CRT410 put a size of 510 (vs 512) into the directory. 
Incidentally, I think this is the reason why DSKCPY changes BADBLK from 
1 to 2 blocks long on the destination disk. 


(6) MEMORY - check for Memory Management in effect 

MEMORY does not check for Memory Management in effect before it does 
its memory assignment. For the first job in bank 0 this is ok. For 
the first job in other banks, however, MEMORY 0 will give the user 
all the memory that can be legitimately given to him, as well as the 
(illegitimate) sharable memory (in most configurations, this is the 
memory immediately below 32K in bank 0). This overlaps JOB1, and will 
cause troubles. 

[thanks. Perk] 

(7) Spooler - Don't abort wildcard spooler kills at first "not found" 

Let's say that you just did a PRINT *.BAS request, and the paper jams, 
and you want to clear out all remaining spool requests without rebooting. 
This is easily done by typing PRINT *.BAS/K, unless the first file has 
finished printing. In the latter case, the spooler finds that the first 
file to be killed from the spool queue is not there, and it quits. 

It would be much nicer if it went on to (attempt) the remaining kills, 
[thanks, Gerry] 

(8) SRCCOM - for blank lines in the output, use CR-LF, not just LF 

If you create a file from SRCCOM output (eg, "SRCCOM BOB.LST=A.B,C.D/Q") 
then try to VUE this file, the blank lines disappear. This is because 
SRCCOM trys to save room by only outputing a LF instead of a CR-LF pair. 
VUE, however, throws away all LFs when it reads in a file. If there is 
no CR included with the blank line, it will be totally lost after VUEing. 


rv> 


AMOS NOTES (Version 4.4) 


(1) Bad Track - some more statistics 

The following table contains bad tracks encountered by us since (4.4). 

The numbers in parentheses are the actual track numbers of the bad tracks. 
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* On this drive, DSK4 had 4 bad tracks (807,808,811,812) and was DOA. 
(2) BADBLK.SYS - format 
















doesn't check Phoenix formats of source and destination 


(3) Octal Generator - how to do it in BASIC 

For those people who need to generate a list of all octal numbers 
from 1 to n, but don't feel up to doing it in assembler, it's easy : 

10 INPUT "ENTER LAST NUMBER (IN OCTAL) : ", LAST 
20 FOR 1=1 TO LAST 
30 N$=I USING "#ZZZ" 

40 IF(INSTR(1,N$,"8")=0 AND INSTR(1,N$,"9")=0) THEN PRINT N$ 

50 NEXT I 

(4) DEL,SYMBOL,WAIT - how are they alike ? 

Anwser : they are the only programs to survive from AMOS 0.1 to 4.4 
without changing (literally) one bit. Runners up are : 

(a) FIXMTM Unchanged since 1.0 

(b) FILDMP Unchanged since 0.1, dropped in 4.4 

(c) TYPE - decreased by 6 bytes since 0.1 1 

(d) REVIVE,CEN.DVR - Same size, different hash 

(5) APPEND - input limited to (buffer - 4) bytes 

If the maximum input buffer length is n bytes for a crt (see TRMDEF in 
SYSTEM.INI), then APPEND will clip off an input line after n-4 bytes 
Two of these 4 bytes is for the cr-lf; the other two are for (?). 

Also, APPEND appears to have no default extensions; "A." and "A" both 
are treated as "A. " by APPEND. 

[thanks, Bill] 

(6) PRINT.TDV - how to make it small 

— Most printers only require a minimal terminal driver. The TELTYP.TDV 
U) takes care of teletype echoing (using backslashes), and is only needed 
for hardcopy terminals. The M40.TDV sends out extra nulls at the end of 
each line (for printers that keep printing during the time that the 
carriage is returning). If you require neither of these, then you can 

use the following driver for your printer - it is only 8 bytes long ! 

WORD 0 

RTN 

RTN 

RTN 

END 

Try it. Put the above into a file named PRINT.MAC, then 
MACRO PRINT 
LOG DSK0:1,6 

COPY PRINT.TDV= PRINT.PRG[p,pn] 

(7) ERASE - how to get auto-query (unsupported) 

If you wish ERASE to default to /QUERY, thereby avoiding some headaches, 
either create a suitable DO file (ERASE.DO), or use the following DDT fix 
LOG SYS: 

COPY ERASEQ=ERASE 
DDT ERASEQ 

PROGRAM BASE IS nnnnn 

PROGRAM SIZE IS 1610 

316/ CLR 1260(R5) SET 1260(R5) 

control-C 

SAVE * 

This works in 4.4; no guarantees for future releases. 

[thanks, Gerry] 


(8) DSKCPY (4.4) 

Phoenix users : another thing to beware of in your conversion from 4.3 
to 4.4 disk format. In 4.3, DSKCPY between Phoenixes was a no-no. 

In 4.4, DSKCPY between 4.4 CRT410'ed disks is ok. Unfortunately, if you 
use 4.4 DSKCPY to copy a 4.3 (old) CRT410'ed disk to a 4.4 (new) CRT410'ed 
disk, DSKCPY evidently doesn't check the BADBLK.SYS file sufficiently to 
find anything amiss, and goes right ahead. Chances are, the destination 
disk will afterwards just sit there and be unreadable, but worst things 
may happen before this is properly diagnosed. 

(9) VUE - memory allocation algorithms clarified & 2 suggestions made 

Upon invoking VUE, VUE loads in each line of the file, throwing away the 
line feed at the end of each line (keeping carriage returns). 

Thus, a file containing 100 empty lines occupies 100 bytes in VUE, not 
0 bytes, nor 200 bytes. The line feeds are restored upon exit from VUE, 
unless VUE leaves IMAGE.VUE in memory. 

If at any time during the program load, VUE finds less than 510 bytes are 
left in its buffer area, it reports so, but loads the remainder of the 
current line. Thus, if VUE was loading the last line, you will find that 
(despite the warning message) that actually the whole file got loaded. 
Also, note that if there are more than 510 characters remaining in this 
"critical" line after the warning is issued, VUE and AMOS will probably 
both immediately crash. Thus : 

SUGGESTION #1 - upon detecting the "large file" condition, VUE 

should "unload" the current line, avoiding the two above problems. 

While inserting in VUE, if VUE finds 32 characters left in its buffer, 
then (without any warning) it will proceed to accept all remaining 
characters, echo them, throw them away, until carriage return is hit. 

At this point, a bell is sounded, but the throw-aways are left displayed. 
If the user returns to this line, probably using control-K, then the 
throw-aways will then be erased, and only successful inserts displayed. 

Any further lines inserted will do the same. They are 100% throw-away. 
Note : A double-escape will re-paint the screen correctly. Thus : 

SUGGESTION #2 - when the memory buffer limit is reached, sound a 

bell, and do no more echoing (just as AMOS does at monitor level). 

[thanks, Lai] 

(10) MAP - switches clarified 

In one buglist I was so brash as to assert that the MAP switches didn't 
work. Well, they do. It's just that they are more demanding than most 
switch sets. Basically, MAP by itself is equivalent to MAP /URMFBSH, as 
stated in the documentation. As soon as a "/" is included, however, all 
default switch options are cleared, and at least 2 or 3 options must be 
entered before MAP can have any logical output. 

All the MAP switch choices that make any sense can be represented by 
the two following groups of switch combinations : 

[R,U) + IM) + (B,S,H} and {F> + (B,S} 

Where the braces indicate that at least 1 letter must be included from 
within that set of switches. If your switches do not satisfy the 
requirements of one of the two groups above, there will be no output ! 



(11) BASIC - some things not in the manual 


The following is no news to long-time AlphaBASIC users. Briefly : 

(a) p 12 - all references to "dynamic length strings" should 

probably be omitted, unless there is any future intentions .... 

(b) p 34 the syntax "IF A <statement>" is not documented 

(c) p 35 either DIM A(10) or DIM A(B) is allowed once, but no 

second DIM A(^.) is allowed in any program. 

(12) LABEL.PRG - pre-dates 4.4 

We have here at Alpha Information Systems a virgin 4.2 Hawk Release disk 
from AM with the following label on block 0 : 

Volume Name : AMOS Version 4.2 System Disk 

Volume ID : SYS42 

Installation : Alpha Microsystems 

System : System C 

Creator : Bob Currier 

(Dated) : 25-Jun-79 

(13) Hashing Algorithm - here it is 

Using a good dis-assembler (DIS.PRG) on MAP.PRG, the hashing algorithm 
can be isolated. I quote the following from 4.4 MAP.PRG : 



MOV 

#2, R5 

go thru the program twice 


CLR 

R3 

R3 = 0 


CLR 

R4 

R4 = 0 

INIT: 

... 


R2 = size of module in words 
R0 = addr of module 

HASH: 

MOV 

(R0)+,R1 

R1 = next word in module 


ADD 

R1,R3 

R3=R1+R3 


ADC 

R4 

R4=R4+carry 


SUB 

R2,R4 

R4=R4-R2 


ADC 

R3 

t R3=R3+borrow (not "-" borrow 


ADD 

R3,R4 

R4=R4+R3 


ADC 

R3 

R3=R3 + carry 


ASL 

R3 

R3=R3*2 


ROL 

R4 

R4=R4*2 + carry 


ADC 

R3 

R3=R3 + carry 


DEC 

R2 

last word ? 


BNE 

HASH 

no, go on to next word 


DEC 

R5 J 

: have we gone thru twice ? 


BNE 

INIT i 

i no, go thru again 




print out last 3 digits in R4 


SWAB 

R4 

swap bytes in R4 

print out last 3 digits in R4 




print out last 3 digits in R3 


SWAB 

R3 

swap bytes in R3 


... ; print out last 3 digits in R3 

Note that the file must be scanned twice. This algorithm has not 
changed since the first release, and probably never will. 

As of 4.4, MAP display hashes in octal or hex (as per SET); DIR always 
gives hashes in octal. 

(14) Disk read times - see full page table following 

Some more timings and a recap of all previous timings. 


DISK READ TIMINGS 


Buglist #13 had some disk read timings. Buglist #14 had some additions. 
Below are both previous tables plus many more timings. Also, there are 
blank spaces provided for all the remaining timings I can think of. 

A hyphen indicates cases for which hardware does not currently exist. 

All timings are given in milliseconds per disk block read. 

For RNDRED, this is an average, usually covering 500 or 1000 reads. 

For REDALL, this is the time of a REDALL divided by the # of blocks. 

The significance of this table is that it gives timings for both the 
slowest case (RNDRED) and the fastest case (REDALL) normally encountered 
in any "routine" disk reading program (excepting DSKCPY and FMTnnn). 

The timings are all efective as of 4.4 (probably the same as 4.3). For 

comparison, the 4.2 timings are given in parenthesis, to show the 

improvement made by version 4.3 . 


Device 

Inter 

Format 

RNDRED 

(4.2) 

REDALL 

(4.2) 

Notes 

ICOM 

ICOM 

STD 



( ) 



( ) 




IMG 



( ) 



( ) 


Persci 

AM200 

AMS 

150 

ms 

(166) 

63 

ms 

(63) 




STD 

23 9 

ms 

(253) 

135 

ms 

(130) 




IMG 

138 

ms 

(648) 

17 3 

ms 

(694) 

a,b,c 

Wangco 

AM200 

AMS 

270 

ms 

(272) 

63 

ms 

(62) 




STD 

365 

ms 

(368) 

128 

ms 

(184) 




IMG 

243 

ms 

(760) 

171 

ms 

(690) 

a, c, d 


AM210 

various 








Shugart 

AM200 

AMS 

— 


(271) 

—- 


(63) 

e 



STD 

— 


(369) 

— 


(196) 

e 



IMG 

— 


( ) 

— 


( ) 

e 

CDC 

AM210 

AMS/DD 

190 

ms 

(-) 

122 

ms 

(-) 

f 



STD/SS 

various 

292 

ms 

(-) 

130 

ms 

(-) 

f 

Trident 

AM400 

Trident 



( ) 



( ) 


Hawk 

AM500 

Hawk 

62 

ms 

(71) 

27 

ms 

(30) 


Phoenix 

AM410 

Phoenix 

50 

ms 

(56) 

17 

ms 

(29) 

9 


Notes : 

(a) remember that IMG format only has 128 bytes per disk read 

(b) note that, for this format, RNDRED is faster than REDALL ! 

(c) note the extraordinarily slow timings before 4.3 

(d) there is evidently a bug in the pre-4.3 Wangco IMG driver; it cannot 
read blocks 1999-2001, giving an error message that refers to block 
2002 (1) The same blocks can be read by 4.4 (without re-formatting). 

(e) Shugarts were not technically supported on the AM200, but some 
bootlegged drivers have been obtained in the past. 

(f) CDC floppies are not supported on the AM200. 

(g) the pre-4.3 timings given are for 4.2.5 






CLASSIFIED 


ADS 


FOR SALE 

5 AM-100 cpu's; 2 AM-200 Controllers; 1 

Equilbox with power supply; 1 Intertube crt; 1 
AM-500 Hawk system; 1 AM-300; Memory boards (8k 

6 64k); Hawk disk packs 

Contact: Richard Starck 412-729-3510 


****** 


FOR SALE 

AM10Q, AM200, AM300; Piiceon 64k memory; Wangco 
87 dual floppy disk drive; TEI power supply and 
chases; Hazeltine 1500 terminal; TI810 Printer 
(upper/lower case) with custom metal stand; 
Triad constant voltage transformer (250 VAC); 
$250.00 worth of diskettes; 1979 Federal and 
California individual income tax package and 
Client write-up program. 

Best reasonable offer for the total package 
will be accepted. 

George K. Kobayashi 
9057 E Imperial Highway 
Downey, California 90242 
213-923-0931 


****** 


John Hewlett writes that he has recently found 
a small business furniture manufacturer who has 
attractive designs and great prices on such 
items as printer stands ($95); printer tables 
($125); CRT tables ($182); and Lazy Susan CRT 
tables ($235). Please send $1.00 to John for a 
full set of flyers and price lists which will 
be credited to your first order. 

Modern Information Methods 
2751 E Chapman Suite 205 
Fullerton, CA 92631 
714-738-6434 


****** 


Thomas Computer is a media supplies dealer and 
a fellow Alpha Micro User; we can offer 
competite pricing of media supplies and have at 
very attractive prices refurbished cartridges 
(5mb @ $44.00 with a three year guarantee). 
Phoenix cartridges are $219.00 for Amus 
members. 


****** 


FORTRAN 

Fortran is now available for the Alpha-Micro. 
For more information, contact 

Absoft 

1169 Lakeside 
Birmingham, MI 48009 
313-646 0060 


* * * * * 


AM - FORTH 

AM-FORTH is available along with some 
comparisons to AlphaBasic from 

George 0. Young III 
Sierra Computer Company 
617 Mark, NE 
Albuquerque, NM 87112 
505 296-8085 


****** 


A / F 0 R T H 


A/Forth from PMS is available in a variety of 
packages with User’s Guide, Installation 
Manuals and an instruction course priced 
separately. 

Professional Management Services 
724 Arastradero, Suite 109 
Palo Alto, CA 94306 
408 252-2218 


* * * * * 


HELP WANTED 


If you have any articles, words of wisdom, 
programs, expertise pr just plain b.s. you 
would like to share with our members, please 
send it to the Editor. Believe it or not, 
sometimes even I run out of things to say. 
Send it on diskette in either AMS or STD format 
and I’ll return or replace your disk. (Sorry, 

I don’t have a Hawk.yet). If it’s short, 

just send the printed copy. 


Hilda M. Polkosky, Sales Manager 
Thomas Computer Corporation 
600 McClurg, Suite 4202 
Chicago, Illinois 60611 
800 - 621-3906 
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ALPHA MICRO USERS SOCIETY 


Software name 


Software Report Form 


Software category 
(legal, medical, etc.) 


Developer _ 

Brief descriptions 


Number of current users: 
References: 


Minimum hardware configuration: 
Special hardware requirements: 


Batch mode: 

yes _ 

_ no _ 

Real time: yes _ 

— 310 

Multi user: 

yes _ 

_ no _ 

Interactive: yes _ 

_ no 


Language: _ 

Documentation supplied: 


Price: 

Hard disk (specify model) Floppy disk (specify format) 

Source _ Source _ 

Object __Object ____________________ 

Company name: _ 

Address: _City: _State: _Zip: _ 

Telephone: _ Contact: _ 

Please complete and return to Sharon Greene, AMUS, P.0. Box 1723, 
Boulder, Colorado 80306 (303) 449-6917 





ALPHA MICRO USERS SOCIETY MEMBERSHIP FORM 


Please fill out as much information as possible. 

Name _ Company _ 

Address _ _ City _ 

State __ Zip Code 

Business Phone _ Home Phone 

Circle one: Own Lease Thinking 

Check all applicable: Dealer _ OEM _ 

User: Corporate _ Individual _ 

Describe equipment: __ 


AMUS may use my name for mailing lists _ 

Make checks payable to AMUS 
Annual dues are $35.00 per member. 

For more information call Sharon Greene at 303/449-6917 or 
write AMUS, P.0. Box 1723, Boulder, Colorado 80306 


Each member representative receives a one ‘/ear subscription 
to the Alpha Micro User's Society Newsletterr the cost 
($ 7 . 50 ) of which is included in the annual dues. 



AMUS 

934 pearl, suite b 
Boulder, CO 80306 


APPLICATION TO MAIL AT SECOND-CLASS 
POSTAGE RATES IS PENDING AT 
BOULDER, COLORADO 80302 



